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Capacity Planning of Resources 

TECHNICAL FIELD 

This invention relates to capacity planning of resources, such as planning of a resource's 

time. 

BACKGROUND 

5 Businesses of all types generally attempt to use their existing resources in the most 

efficient and organized manner. For example, a professional consulting business may attempt to 
fill the schedule of each consultant (a resource) with client-related work between the hours of 
8:00 AM and 5:00 PM so as to use the full capacity of time provided by that consultant. 
Similarly, a technology service business may attempt to schedule a skilled technician (a resource) 

10 as a field service technician (servicing/repairing products at various locations) two days per week 
and as a call center agent (providing technical support via telephone or internet communications) 
three days per week. Such a schedule for the skilled technician may efficiently distribute the 
technician's capacity of time. In another example, a manufacturing plant may use a single 
machine (a resource) to manufacture several different products, but the machine must be shut 

15 down for a period of time when new tooling must be set-up for the manufacture each of the 
different products. Thus, the machine's capacity to build the different products may be 
efficiently scheduled by reducing the number of tooling changes. 

Conventional scheduling systems may permit an operator to schedule a resource's time to 
an assignment having concrete date and time facts. For example, a conventional system may 

20 schedule an assignment to a skilled technician to work as a field service technician on Monday 
from 9:00 AM to 6:00 PM and then to work as a call center agent on Tuesday from 8:00 AM to 
5:00 PM. The concrete date and time facts for this assignment permit the system to reserve the 
worker's time on Monday and Tuesday for the specified tasks. In another example, a 
conventional system may schedule an assignment for a professional consultant to work on a 

25 client's project from 8:00 AM to 5:00 PM on Monday, June 16. Because the date and time facts 

are concrete, the conventional system may reserve the consultant's time. 

Problems arise when a request for a resource's time does not include concrete date and 

time facts. If, for example, a request for a consultant's time specifying only that the consultant 

must spend twenty hours in the month of April working on a particular project, the required 
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concrete date and time facts would be lacking. Some conventional systems may not be able to 
handle such a non-concrete assignment. Other may automatically schedule such a non-concrete 
assignment in a potentially inefficient manner (e.g., scheduling one hour per day for the first 
twenty work days in April even though the consultant is already scheduled at 100% capacity on 
5 one or more of those days). 

SUMMARY 

Certain implementations of the invention provide a resource planning system or method 
for receiving a scheduling request for a resource's time where the scheduling request includes a 
date range and the estimated amount of time needed from the resource, but does not include 

10 concrete date and time facts. This first scheduling request may be refined by a second 

scheduling request, which specifies concrete date and time facts to schedule a portion of the 
resource's time that was originally requested by the first scheduling request. In such 
implementations, the resource's time may be scheduled in an efficient manner without over- 
scheduling or double-booking the resource's time. 

1 5 In one implementation, a method of scheduling use of a resource includes receiving a 

first scheduling request for a resource. The first scheduling request specifies that the resource is 
to be scheduled for a requested amount of time sometime within a requested time period — the 
requested amount of time being less than a maximum time amount that the resource is available 
during the requested time period. The method further includes receiving a second scheduling 

20 request for the resource that refines the first scheduling request. The second scheduling request 
specifies that a portion of the requested amount of time is to be scheduled in a specific time slot 
within the requested time period. The method also includes scheduling in an electronic schedule 
the portion of the requested amount of time in the specific time slot, and scheduling in the 
electronic schedule a remaining portion of the requested amount of time within the requested 

25 time period except within the specific time slot. 

The systems and techniques described herein may provide any or all of the following 
advantages. Improved scheduling of a resource. Improved determination of a resource's 
workload. Improved use of a scheduling program. Improved scheduling of concrete and non- 
concrete requests for use of a resource. Providing that the impact of a non-concrete scheduling 

30 request on a resource's schedule properly takes into account a concrete refinement of that non- 
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concrete request. Providing that, when a non-concrete scheduling request is refined by a 
concrete request, the remainder of the non-concrete request is properly distributed in the 
resource's schedule. Providing that, when a non-concrete scheduling request is refined by a 
concrete request, the remainder of the non-concrete request is distributed in the resource's 
5 schedule to avoid overscheduling the resource. 

The details of one or more embodiments of the invention are set forth in the 
accompanying drawings and the description below. Other features, objects, and advantages of 
the invention will be apparent from the description and drawings, and from the claims. 

DESCRIPTION OF DRAWINGS 
10 FIG. 1 is a diagram of a computer system in accordance with one implementation of the 

invention. 

FIGS. 2A-C are graphical representations of a resource's time capacity in accordance 
with an implementation of the invention. 

FIGS. 3A-C are graphical representations of a resource's time capacity in accordance 
1 5 with another implementation. 

FIG. 4 is a flow chart for the process of scheduling the use of a particular resource, in 
accordance with one implementation of the invention. 

Like reference symbols in the various drawings indicate like elements. 

DETAILED DESCRIPTION 

20 Referring to FIG. 1, a computer system 100 includes a processor 110 and memory 120 

coupled to a computer bus 130 or other suitable interconnect. The memory 120 has a resource 
planning application 122 and a resource database 124 stored thereon. The resource planning 
application 122 is capable of receiving (e.g., includes executable instructions for receiving) 
information from the resource database 124 and capable of transmitting (e.g., includes 

25 executable instructions for transmitting) new information to the resource database 124. For 
example, the resource database 124 may include information on certain workers in a business 
and the time availability of those workers. In such a case, the resource planning application 122 
is capable of receiving worker availability information from the resource database 124 so as to 
schedule a new assignment for that worker in a time slot of an electronic schedule. When the 

30 new assignment is scheduled, the worker's availability information in the resource database 124 
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is modified accordingly. In some implementations, a computer program product installed onto 
the memory 120 may include the resource planning application 122, of which the electronic 
schedule is a sub-application. Alternatively, the electronic schedule may be a separate 
application stored on the memory 120. In the examples below, the scheduling of a resource is 
5 what determines the use of that resource. Alternatively, scheduling may be used to estimate the 
utilization of the resource; that is, to determine the workload of the resource although the 
scheduling does not actually govern the use of the resource. Thus, the systems and techniques 
described herein may be used for directly managing a resource's workload or for determining the 
resource's workload. 

10 The resource planning application 122 is capable of receiving requests for a resource's 

time. For example, a consulting firm may use the resource planning application 122 to manage 
the schedules of consultants (resources). In such a situation, a client or a scheduling manager 
may request that a particular consultant — or any consultant having particular qualifications — 
work on project for a certain number of hours. The resource planning application 122 may 

15 receive non-concrete requests that include a date range and the estimated amount of time needed 
from the resource, but does not include concrete date and time facts. For example, the non- 
concrete request may ask for a consultant to work for forty hours (i.e., the estimated amount of 
time) on a project at any time in the month of January (i.e., date range of January 1-31). This 
non-concrete request may be later refined by a subsequent concrete request, which specifies 

20 concrete date and time facts to reserve at least a portion of the resource's time that was originally 
requested by the non-concrete request. Continuing with the previous example, the concrete 
request may ask for the consultant to work on a particular aspect of the project for eight hours on 
January 1 5 during the time slot of 8:00 AM to 4:00 PM, thus permitting the remaining thirty-two 
hours from the original request to be served on other days in January. By permitting the 

25 resource's time to be initially reserved with a non-concrete request and then later refined with a 
concrete request, the resource's time may be scheduled in an efficient manner without over- 
scheduling or double-booking. 

Still referring to FIG. 1, the processor 110 and memory 120 are interconnected to at least 
one I/O (input/output) device 140 in the computer system 100. The I/O device 140 can be 

30 connected with one or more user interface devices 150, such as a keyboard, mouse, display, or 
the like. The user interface devices 150 permit a user of the computer system 100 to interact 
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with various components of the computer system 100 or permit a user to cause certain processes 
to be executed. The I/O device 140 may be connected to a network 160, such as the Internet or a 
local area network. The connection with the network 160 permits the computer system 100 to 
communicate with one or more remote computer systems 170. For example, a remote computer 
5 system 170 may include a resource planning application 172 similar to the previously described 
application 122. In such an implementation, the resource planning application 172 of the remote 
computer system 170 may receive information from the resource database 124 via the network 
connection. Thus, the resource planning application 172 may be capable of receiving 
information from the resource database 124 and capable of transmitting new information to the 

10 resource database 124. 

In some implementations, the computer system 100 may be a server system and the 
remote computer system(s) 170 may be remote workstations with which the server system 100 
maintains network connections. The server system 100 includes memory that has the resource 
planning application 122 and the resource database 124 stored thereon. The resource planning 

15 application 122 and the resource planning application 172 of the remote workstation system 170 
may receive information from the database 124 and likewise transmit information to the database 
124. Such an implementation may be used, for example, by businesses where more than one 
manager or human resources professional has the authority to schedule a worker's time. In such 
circumstances, that worker's availability information is stored in the resource database 124, and 

20 each manager may use a personal workstation system 170 to schedule a portion of that worker's 
available time using a resource planning application 172. Because all of the resource planning 
applications 172 (at the different workstation systems 170) receive information from one 
resource database 124 on the server system 100, a manager at one workstation system 170 may 
have access to the worker's time availability information as modified by another manager on 

25 another workstation system 170. In one example, a manager that intends to schedule a service 
technician to work in a technical support call center on either Thursday or Friday would be able 
to know that the service technician was previously scheduled by a different manager to work as a 
field service technician on Thursday. 

FIGS. 2A-C are a conceptual example illustrating operations in a resource planning 

30 application. Particularly, these figures show how a non-concrete request for a resource's time 

may be received and scheduled, followed by the receipt and scheduling of a concrete refinement 
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thereof. In this example, the resource's total availability over three days — here, June 10, 11, and 
12 — is schematically illustrated in date range 200. The number of hours that can be scheduled 
each day are measured by the horizontal axis 210 — in this example, the resource is available for 
eight hours each day (8:00 AM — 4:00 PM). The amount of the resource's capacity that is being 
5 used is measured against the vertical axis 220, in this example marked with 0% and 100%) 
levels. Such characterizations of the resource's available time may be included with the 
availability information of the resource database 124 or may be implemented by the electronic 
schedule for that resource. 

In the graphic representation of the resource's capacity, the resource would be fully 

1 0 utilized if scheduled to 1 00% capacity for each day. For example, if a professional consultant (a 
resource) is available for eight hours on June 10, and a client requests that the consultant work on 
a project for eight hours that day, the resource is fully utilized (100%) capacity. On the other 
hand, if the consultant is available for eight hours on June 10, but no clients have requested a 
portion of the consultant's available time, the resource is not fully utilized for that day (0% 

1 5 capacity). If a client has requested the consultant to work on a project that requires only four 

hours on June 10, the impact on the consultant's availability would be equivalent to the resource 
being used at 50% capacity for that day ([4 hours of scheduled time]/[8 hours of available time] 
= 50% use of total availability). Thus, the consultant would be able to spend four hours on the 
client's project while the remaining four hours would be available for another work project or, if 

20 no other project is scheduled, for doing the nonclient-related work (possibly, with no direct 
revenue to the business). 

Referring to FIG. 2 A, a resource has a total availability 210 of eight hours on each day 
between June 10 and June 12. In this example, the resource is available from 8:00 AM to 4:00 
PM (eight hours of total availability) on each of the days, but the total availability 210 may be 

25 divided into arbitrary time periods that amount to eight hours. At this point, the availability 

information for this resource includes no scheduled assignments to complete on these days, so 
the resource is scheduled to be used at 0% capacity 220 on June 10-12. This availability 
information for the resource may be stored in a resource database (e.g., the database 124 from 
FIG. 1). 

30 Referring to FIG. 2B, the resource planning application (e.g., the application 122 from 

FIG. 1) receives a non-concrete request for sixteen hours of service from the resource sometime 
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on the dates of June 10-12. In one example where the resource is a professional consultant, such 
requests for the resource's time may come from a remote resource planning application 172 used 
by the consultant's client or by the consulting firm's scheduling manager. The request for the 
resource's time is non-concrete because it does not specify the exact allotment of hours for each 
5 day. Rather, it merely requests sixteen hours of the resource's time to be distributed sometime 
between June 10 and June 12. The resource planning application receives the availability 
information from the resource database to verify that the resource has available time on those 
dates (as graphically represented in FIG. 2 A, the resource has a total of twenty-four available 
hours between the days of June 10-12). Because the resource had no other assignments 
10 scheduled for the three-day period 200, the resource planning application evenly distributes the 
non-concrete request into portions 231, 232, and 233 over the three-day period 200. The purpose 
of including the non-concrete request in the resource's schedule is to take into account the 
impact it will have on the availability of the resource. In this implementation, the non-concrete 
request is apportioned into 5-1/3 hours for each day so as to reserve a total of sixteen hours. In 
15 some embodiments, such an assignment may be scheduled in an electronic schedule that allots 

the 5-1/3 hours into actual time slots (e.g., 8:00 AM to 1:20 PM), thus reserving that time slot for 
the resource to serve/work on the desired task. Because the 5-1/3 hour portions 231, 232, and 
233 are from a non-concrete request, the scheduled time slots may be modified to accommodate 
a subsequent concrete request (explained in more detail below). As shown in FIG. 2B, the non- 
20 concrete assignment has an impact on the resource's availability that is equivalent to the resource 
being used at 66.6% capacity for each day in the three-day range 200. 

Referring to FIG. 2C, the resource planning application is capable of receiving a concrete 
request that is a refinement of the previously described non-concrete request. In this example, 
the refinement is a concrete request that specifies the resource must serve eight hours (out of the 
25 originally requested sixteen hours) on June 1 1 during the time slot of 8:00 AM to 4:00 PM. The 
resource planning application verifies with the availability information that the resource is 
available for the requested time intervals (e.g., by verifying that the resource does not have any 
concrete assignments scheduled in the requested time intervals), and then redistributes the 
resource's schedule. As shown in FIG. 2C, the resource planning application distributes the 
30 concrete request into a portion 240 on June 1 1 . The portion 240 has different cross-hatching to 
distinguish it from the non-concrete portions 231, 232 and 233. In this example, the concrete 



7 



Attorney Docket No. 1 3906- 1 8000 1 / 2004P00204 US 

portion 240 is scheduled in the electronic schedule according to the time slots specified in the 
concrete request (8:00 AM to 4:00 PM ). The portion 240 accounts for the eight hours covered 
by the concrete request, which is a refinement of the sixteen hours originally requested as part of 
the non-concrete request. 

5 When the non-concrete request (sixteen hours) is refined by the concrete request (eight 

hours), there are eight hours remaining from the non-concrete request. These hours need to be 
distributed in the date range 200 to give a realistic idea of how much of the resource's capacity is 
still available. If the remaining eight hours were distributed evenly throughout the three-day 
range 200, the resource would be scheduled in excess of its 100% capacity on June 11. The 

10 remaining eight hours are therefore scheduled while taking the portion 240 from the existing 

concrete assignment into account. That is, the eight hours of concrete assignment scheduled on 
June 1 1 are subtracted from the resource total availability, and the remainder of the non-concrete 
request (eight hours) is distributed elsewhere in the date range 200. In so doing, the resource 
planning application accounts for the portion 240 of time reserved by the concrete request and 

15 modifies the resource's availability information. Then, the resource planning application 

redistributes the remaining eight hours into portions 251 and 252 using the modified availability 
information. Thus, the resource planning application schedules the non-concrete portions 251 
and 252 into the electronic schedule, but not in the time slots reserved by the concrete request. 
As shown in FIG. 2C, the concrete request caused the resource to be scheduled at 100% 

20 capacity on June 1 1, so the resource's only available time in the three-day period 200 is the eight 
hours on June 10 and the eight hours on June 12. After accommodating for portion 240, the 
resource planning application redistributes the remaining eight hours into two portions 251 and 
252, one for each day of June 10 and June 12. Each portion 251 and 252 corresponds to four 
hours of work, reserving a total of eight hours that equals the remaining eight hours from the 

25 original non-concrete request. As such, the non-concrete assignment and subsequent concrete 
refinement have an impact on the resource's availability that is equivalent to the resource being 
used at 50% capacity on June 10, 100% capacity on June 1 1, and 50% capacity on June 12. This 
availability information may be included in the resource database so that the resource's 
availability is accurately reflected when the next scheduling request is received by the resource 

30 planning application. 
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A non-concrete request can be handled also when a portion of the resource's time is 
already reserved due to a previously-accepted concrete request. The previously described FIGS. 
2A-C were a conceptual example illustrating how a non-concrete request for a resource's time 
may be received and scheduled, followed by the receipt and scheduling of a concrete refinement 
5 thereof. FIGS. 3A-C are similar in that the number of hours that can be scheduled each day are 
measured by the horizontal axis 310, but in this example, the resource is available for four hours 
each day (12:00 PM— 4:00 PM). FIGS. 3A-C are also similar to the previously described FIGS. 
2A-C in that the amount of the resource's capacity that is being used is measured against the 
vertical axis 320. 

10 As shown in FIG. 3 A, the resource's total availability 310 is four hours for each day in 

the three-day period 300 between August 12 and August 14. In this example, the resource is 
available from 12:00 PM to 4:00 PM (four hours of total availability) on each of the days, but the 
total availability 210 may be divided into arbitrary time periods that amount to four hours. 
Before the resource planning application receives a non-concrete request for the resource's time 

15 over this date range 300, a separate concrete request for a portion 325 of the resource's time was 
previously accepted and scheduled. The previously-accepted portion 325 accounts for three 
hours of the resources time, and is scheduled in the electronic schedule, for example, in the time 
slot of 12:00-3:00 PM. The availability information for the resource, including the time reserved 
by the previously-accepted concrete request, may be stored in the resource database 124 (FIG. 1). 

20 According to the availability information at this point, the previously-accepted concrete request 
has an impact on the resource's availability that is equivalent to the resource being used at 100% 
for three hours on August 12, 0% on August 13, and 0% on August 14. 

Referring to FIG. 3B, the resource planning application receives a non-concrete request 
for seven hours of the resource's services sometime on the dates of August 12-14. Rather than 

25 distributing the requested seven hours into three 2-1/3 hour portions (one equal portion for each 
day), which would cause the resource to be overbooked on August 12 (scheduled at 133% 
capacity), the resource planning application distributes the requested time into portions such that 
the resource is never scheduled to exceed 100% capacity on any day. Because the availability 
information shows that the available hours are not equal for each day in the three-day period 300, 

30 the requested seven hours is distributed into three non-concrete portions 331, 332, and 333 that 
are not all equal. The seven hours requested by the non-concrete request are distributed over the 
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available time; that is, over one hour on August 12 and over the four available hours on each of 
August 13 and 14. The amount of time scheduled in each of these time slots is such that the 
impact of the non-concrete request is equal over the available hours (the portions 33 1, 332 and 
333 have the same height.) 
5 Referring to FIG. 3C, the resource planning application is capable of receiving a concrete 

request that is a subsequent refinement of the previously described non-concrete request for 
seven hours. In this implementation, the refinement is a concrete request that specifies the 
resource must serve four hours (out of the originally requested seven hours) on August 13 during 
the time slot of 12:00-4:00 PM. The resource planning application verifies that the resource is 

10 available for this requested time interval by referring to the availability information in the 

resource database. Because the only time reserved on August 13 was a portion 332 from the 
non-concrete request, of which the concrete request is merely a refinement, the resource planning 
application would accept the concrete request for August 13. If, however, the concrete request 
had been for August 12, the resource planning application may have rejected the concrete request 

15 because the previously-accepted portion 325 negates an additional fours hours being scheduled 
on that day (because the resource would be scheduled to operate in excess of 100% capacity). 

As shown in FIG. 3C, the resource planning application distributes the concrete request 
into a portion 340 on August 13. In this example, the concrete portion 340 would be scheduled 
in the electronic schedule according to the time slot that specified in the concrete request (12:00- 

20 4:00 PM). The portion 340 represents the fours hours requested by the concrete request, which 
was a refinement of the seven hours originally requested as part of the non-concrete request. 

After scheduling the concrete refinement in the electronic schedule, the resource planning 
application redistributes the remaining three hours from the non-concrete request (seven hours) 
that were not accounted for by the concrete refinement (four hours). The application does not 

25 distribute the remaining three hours into three 1-hour portions (one portion for each day), which 
would cause the resource to be overbooked on August 13 (scheduled at 125% capacity). Rather, 
the resource planning application accounts for the portion 340 reserved by the concrete 
refinement and the previously-accepted portion 325 reserved by the separate concrete request by 
updating the resource's availability information. Then, the resource planning application 

30 redistributes the remaining three hours into portions 35 1 and 352 using the updated availability 
information. Thus, the resource planning application schedules the non-concrete portions 351 
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and 352 into the electronic schedule, but not in the time slot reserved by the previously-accepted 
concrete request (12:00-3:00 PM on August 12) or by the concrete refinement (12:00-4:00 PM 
on August 13). In this example, the remaining three hours from the non-concrete request are 
distributed into a portion 35 1 on August 12 and a portion on August 14 that have equal heights 
5 on the vertical axis 320. 

The graphic representations of the resource's capacity in FIGS. 2A-C and 3A-C provide 
examples of receiving non-concrete requests for a resource's time and receiving subsequent 
concrete refinements, but the invention is not limited to such examples. Many implementations 
of the invention may receive the non-concrete requests and the subsequent concrete refinements 

1 0 and then distribute the time differently from the examples described above. 

Referring to FIG. 4, some implementations of a method 400 for scheduling use of a 
resource includes receiving in step 410 a first scheduling request that includes a non-concrete 
request for the resource's time within a specific date range. For example, the first scheduling 
request may specify that the resource be scheduled for a requested amount of time (e.g. sixteen 

15 hours) sometime within a requested time period (e.g., between July 1, 8:00 AM and July 8, 5:00 
PM). In such an example, the requested amount of time (sixteen hours) should be less than a 
maximum time amount that the resource is available during the requested time period (e.g., total 
availability for July 1-8 is forty hours); otherwise, the first-scheduling request would be denied 
due to the resource's unavailability. 

20 Optionally, the method 400 may also include receiving in step 420 all time slots in which 

the resource is available within the specific date range. Depending on the type of availability 
information stored in the resource database or the format of the electronic schedule, the 
resource's availability of time may be maintained as a set of time intervals. For example, the 
resource database may store the resource's availability information in fifteen-minute intervals 

25 (e.g., 8:00-8:15AM, 8:15-8:30 AM, . . . , 4:45-5:00 PM) such that an assignment may be 

scheduled to occupy one or more of these intervals. In such an implementation, the resource 
planning application may receive all unassigned time slots in the specific range, which may be 
combined to reflect the resource's total availability in that date range. 

The method 400 further includes receiving in step 430 a second scheduling request that is 

30 a refinement of the first scheduling request and includes a concrete request for a portion of the 
requested time in a specific time slot of the resource's available time. Continuing with the 
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previous example in which the first scheduling request was for sixteen hours within the dates of 
July 1-8, the second scheduling request may include concrete date and time facts such as a 
request for eight hours (out of the originally requested sixteen hours) to be scheduled on July 2 
from 12:00-8:00 PM. In this implementation, the resource planning application may refer to the 
5 resource's availability to verify that the resource has sufficient capacity on July 2. 

The method 400 includes scheduling in step 440 in an electronic schedule the portion of 
the requested time in the specific time slot according to the second scheduling request. Referring 
the previous example, the concrete request included a request for eight hours on July 2 from 
12:00-8:00 PM, and that time slot would be assigned in the electronic schedule so as to reserve 

10 that interval of time according to the second scheduling request. 

The method 400 also includes scheduling in step 450 in the electronic schedule the 
remaining portion of the time requested by the first scheduling request. The remaining portion of 
time is scheduled within the specific date range, but not in the specific time slot that was 
scheduled according to the second scheduling request. In one implementation, the resource 

15 planning application may receive an update of all time slots in which the resource is available 
within the specific date range, yet the specific time slot is not included in this updated set 
because it was reserved according to the second scheduling request. As such, the remaining 
portion of the time requested by the first scheduling request may be distributed into this set of 
available time slots without scheduling the resource to operate at a capacity in excess of 100% on 

20 any given date. Continuing with the previous example, the remain eight hours (that was not 

accounted for in the second scheduling request) would be scheduled into the electronic schedule 
between July 1 and July 8, but not in the specific time slot (July 2 from 12:00-8:00 PM) reserved 
according to the second scheduling request. 

The previously described implementations of the invention refer to the resource's time in 

25 terms of hours on a given date, but the invention is not limited to such implementations. Rather, 
a resource planning application may schedule the resource's time in terms of seconds, minutes, 
hours, shifts, days, or any other suitable time units. 

In addition, some implementations have been described to include a professional 
consultant or a service technician as the "resource" that has available time. The resource 

30 planning application is not limited to such implementations. For example, the resource may be a 
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machine, a person such as a worker, a tool, a workstation, or any other resource that may be fully 
utilized by efficient scheduling. 

The invention can be implemented in digital electronic circuitry, or in computer 
hardware, firmware, software, or in combinations of them. Apparatus of the invention can be 
5 implemented in a computer program product tangibly embodied in an information carrier, e.g., in 
a machine-readable storage device or in a propagated signal, for execution by a programmable 
processor; and method steps of the invention can be performed by a programmable processor 
executing a program of instructions to perform functions of the invention by operating on input 
data and generating output. The invention can be implemented advantageously in one or more 

10 computer programs that are executable on a programmable system including at least one 

programmable processor coupled to receive data and instructions from, and to transmit data and 
instructions to, a data storage system, at least one input device, and at least one output device. A 
computer program is a set of instructions that can be used, directly or indirectly, in a computer to 
perform a certain activity or bring about a certain result. A computer program can be written in 

15 any form of programming language, including compiled or interpreted languages, and it can be 
deployed in any form, including as a stand-alone program or as a module, component, 
subroutine, or other unit suitable for use in a computing environment. 

Suitable processors for the execution of a program of instructions include, by way of 
example, both general and special purpose microprocessors, and the sole processor or one of 

20 multiple processors of any kind of computer. Generally, a processor will receive instructions and 
data from a read-only memory or a random access memory or both. The essential elements of a 
computer are a processor for executing instructions and one or more memories for storing 
instructions and data. Generally, a computer will also include, or be operatively coupled to 
communicate with, one or more mass storage devices for storing data files; such devices include 

25 magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and 
optical disks. Storage devices suitable for tangibly embodying computer program instructions 
and data include all forms of non-volatile memory, including by way of example semiconductor 
memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as 
internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM 

30 disks. The processor and the memory can be supplemented by, or incorporated in, ASICs 
(application-specific integrated circuits). 
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To provide for interaction with a user, the invention can be implemented on a computer 
having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor 
for displaying information to the user and a keyboard and a pointing device such as a mouse or a 
trackball by which the user can provide input to the computer. 

The invention can be implemented in a computer system that includes a back-end 
component, such as a data server, or that includes a middleware component, such as an 
application server or an Internet server, or that includes a front-end component, such as a client 
computer having a graphical user interface or an Internet browser, or any combination of them. 
The components of the system can be connected by any form or medium of digital data 
communication such as a communication network. Examples of communication networks 
include, e.g., a LAN, a WAN, and the computers and networks forming the Internet. 

The computer system can include clients and servers. A client and server are generally 
remote from each other and typically interact through a network, such as the described one. The 
relationship of client and server arises by virtue of computer programs running on the respective 
computers and having a client-server relationship to each other. 

A number of implementations of the invention have been described. Nevertheless, it will 
be understood that various modifications may be made without departing from the spirit and 
scope of the invention. Accordingly, other implementations are within the scope of the following 
claims. 
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